A simple Event Driven Application is one that responds to actions generated by the user or the system. Event Driven Applications can perform a predetermined sequence of actions depending, for example, on a sequence of actions and/or events with which they are presented. Simple examples of Event Driven Applications include vending machines that dispense products when the proper combination of coins is deposited, combination locks that require the input of combination numbers in the proper order, etc. Although these examples are simple, it is known that Event Driven Applications can model a large number of potentially complex problems such as, for example, electronic design automation, communication protocol design, language parsing, engineering applications, and/or the like.
It will be appreciated that in a good Service-Oriented Architecture (SOA) Governance solution, the careful development of services/applications may help to determine the value it adds to the business. Unfortunately, however, the development and evolution of the services are determined by a series of lifecycle states and events that are difficult to track and/or monitor, thus making it difficult to provide useful information to application/service developers and/or other interested stakeholders.
For example, recording of the evolution of applications and what happens as such applications go through multiple states/events during development and as they are used when actually deployed, can impose potentially significant requirements, e.g., when it comes to gathering data relevant to analyzing and understanding the important design decisions made throughout its evolution, as well as for application maintenance and anomaly resolution during development and deployed use.
The inventors have also realized that additional or alternative benefits could be derived from careful recording of the interactions with the aforementioned applications, e.g., based on observed and/or adduced interaction patterns. Interaction patterns can, for example, be studied to build intelligent applications that can automatically or at least semi-automatically determine new application workflows based on previous interactions that it had with the particular user. Examples of such changed flows may include, for example, dynamically changing a GUI according to analysis of human interaction patterns. Building a dynamic system, e.g., where less frequently used parts of an application filtered and user-preferred flows are at least initially shown, may reduce the number of “clicks” performed on a GUI and thus may improve the efficiency of the interactions, while creating a more natural feeling and easier to use application. Unfortunately, however, it oftentimes is difficult to gather this information, as well, and it therefore is difficult to enable solutions of these sorts.
Although some current attempts to have been made to use event driven auditing to build “audit logs” or the like, such techniques stop short of actually interpreting those logs to build intelligent systems. And although some tools have been developed for processing audit logs to collect and analyze the events so as to determine further courses of actions (e.g., like raising an alarm in monitoring systems, etc.), such approaches likewise stop short of actually instilling intelligence into applications, e.g., based on the events and logs.
Thus, it will be appreciated by those skilled in the art that it would be desirable to overcome these and/or other problems. For example, it will be appreciated that it would be desirable to build application intelligence on Event Driven Applications by effective recording of application evolution and usage.
One aspect of certain example embodiments relates to effective recording of application evolution and usage for usage learning and/or event auditing purposes. With respect to usage learning, certain example embodiments may help to capture data on the usage patterns and/or apply learning algorithms that work on the captured data to provide required intelligence to the application. With respect to event auditing, certain example embodiments may help to identify the “who”, “what”, “when”, “where”, “how”, and/or “why” of particular operations, e.g., to respectively identify for a given operation or combination of operations the user who is performing the particular operation on the application; what operation is being performed by the user on the application; the time at which the operation is being performed; the physical location at which the operation is performed; how the operation is performed (e.g., manually, automatically, some combination thereof, etc.); and the reason(s) behind the operation.
Another aspect of certain example embodiments relates to using application intelligence to determine application “hotspots” or commonly used features (including those that are most common) that help in areas such as application maintenance, performance tuning, and/or the like.
Another aspect of certain example embodiments relates to using application intelligence to equip an application with knowledge about different users' usage patterns, e.g., so that the application can present different workflows tailored for different users for the same application.
In certain example embodiments, an application intelligence gathering method for use with an application hosted by a computer system is provided. Artifacts are received from a computer readable storage medium, with the artifacts representing data gathered during execution of the application and relating to events that occur during the execution. Using a computer processor, interaction patterns associated with the events are identified. Inference documents are generated in connection with the identified interaction patterns using the computer processor. The inference documents include, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event. Using the computer processor, at least one custom application workflow is generated based on the generated inference documents. The at least one custom application is transformable into a new application workflow that is deployable into the application.
In certain example embodiments, there is provided a non-transitory computer readable storage medium tangible storing instructions that, when performed, gather application intelligence on an application hosted by a computer system, by executing instructions to at least: receive artifacts from a computer readable storage medium, the artifacts representing data gathered during execution of the application and relating to events that occur during the execution; identify interaction patterns associated with the events; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application.
In certain example embodiments, a computer system for gathering application intelligence on an application is provided. Processing resources include at least one processor and a memory. A computer readable storage medium tangibly stores data gathered during execution of the application and relating to events that occur during the execution. At least some of the processing resources are configured to at least: identify interaction patterns associated with the events, using the computer readable storage medium; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow potentially being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application. The data gathered during execution of the application indicates, for each said event, what kind of event was performed, why the event happened, who was responsible for triggering the event, when the event happened, where the event happened, and how the event was triggered, as appropriate for the respective event.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations and sub-combinations to achieve yet further embodiments of this invention.